关注刷新和 MCP 的 get_follows 改成按关注分组读名单 - #466

有用户反馈关注 4000 多个时刷新很慢。第 1 步每次都逐页读 followings，一页最多 50 人，4000 人要 80 个请求，连着翻还容易被限流。

• 已有完整名单时，第 1 步按关注分组读（x/relation/tag，一页 500 人，x/relation/tags 说没人的分组不读）。分进自定义分组的人不在默认分组里，所有分组合起来就是全部关注，按 mid 去重。4000 人约 10 个请求。有人的分组第 1 页回空当作可能的风控，再问一次。
• 分组接口不带关注时间。从 followings 第 1 页往后读，直到某页没有新人，读到的人都用它的时间（取关后又关注的人也更新），没读到的沿用存着的。人数和 followings 的总数对不上时退回逐页读，不会漏人。第一次同步照旧逐页读。
• 读法抽成 followReadGroups，MCP 的 get_follows 没同步过时也用它读整份名单，query 能用了，读全的结果缓存 3 分钟供翻页。MCP 同样核对总数，读不全就退回原来的读一页，且不缓存。MCP 用自己的请求方式，限流直接报 THROTTLED，不走关注队列的 90 秒等待，避免超过一次调用的时限。
• 顺带修好一处：B站 删掉分组后，followings 还会给原成员挂着已删除分组的 id，分组接口给的是对的。

验证：node scripts/selftest.mjs 50 项通过，cd mcp && npm test 22 项通过。用真实登录（971 人）实测：

• 在临时分组里放 1 人，默认分组少了他，合并后正好等于原名单。测完删掉分组，复查已还原。
• 按分组读和逐页读结果一致（名单、关注时间、特别关注、分组、名字头像），只有两个同一秒关注的人先后顺序不同。
• 在装着的扩展页里用分支代码跑第 1 步，读写真实存储：5 个请求、5.5 秒，原来是 20 个。「已刷新 +0 −0」，取消关注记录没变。
• MCP 的读法：4 个请求、5.2 秒读完，前 50 人和「最新关注在前」的顺序一致。

没测：关注超过 1000 人或有多个自定义分组的账号；从 MCP 客户端走完整一趟（端口被正在用的 MCP 服务占着）。不带上下文的子 agent 审过 diff，确认的问题已修。

mcp/server.js 只改了 get_follows 的说明，发版时要提升 MCP 版本号 npm 才会发新版。